Skip to content

Conversation

@MaisenbacherD
Copy link
Contributor

Previously we used two independent ARC deployments where one compiled/announced the kernel and the second spun up a VM that executed our tests.

This setup caused concurrency related issues in other projects that use the same infrastructure. An ARC can assign work to any available resource (in our case the VM) and thus we could not guaranty which kernel was used for testing.

We are now using a single ARC that can build and spawn a VM. To spawn and run commands in the VM we are now using the kubevirt-action defined in linux-blktests/blktests-ci.

Previously we used two independent ARC deployments where one
compiled/announced the kernel and the second spun up a VM that executed
our tests.

This setup caused concurrency related issues in other projects that use
the same infrastructure. An ARC can assign work to any available resource
(in our case the VM) and thus we could not guaranty which kernel was used
for testing.

We are now using a single ARC that can build and spawn a VM.
To spawn and run commands in the VM we are now using the kubevirt-action
defined in linux-blktests/blktests-ci.

Signed-off-by: Dennis Maisenbacher <[email protected]>
@igaw igaw merged commit ae099f5 into linux-nvme:master Jul 9, 2025
17 checks passed
@igaw
Copy link
Collaborator

igaw commented Jul 9, 2025

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants